I'm setting up a 3W laser diode on my CNC router (which has kflop & kstep), and I want to share my idea for switching the laser on/off so that people more familiar with kflop can give me any better suggestions.

The laser driver draws ~1.7A@12V so I will use relay output 0 to drive a normal mechanical relay which powers the laser. When I have time I'll try to find a suitable NPN to get faster switching than a relay.

My G-code is created to suit engraving, so it has "G0 Z#1" to raise the tool (safe Z moves) and "G1 Z#2" to lower the tool (start cutting). So I was planning to use find/replace in my G-code to swap all "G0 Z#1" lines to M110, and all "G1 Z#2" to M111.

M110 would then call a laser-switch-on thread including SetBit(0); and M111 would call a laser-switch-off thread including ClearBit(0); If I find that the laser takes a while to switch on, I could pause motion with a "G4 0.25" after each of my M code calls to allow time to start/stop the laser

Does that sound like a fairly logical method?

The second approach that I was considering, was not to use the M-codes at all, and basically execute a c program that turns on the laser on if the z value matches the engraving value. eg:

if(ch2->Position==-0.2) // If gcode says to lower engraving tool

{

SetBit(0); //turn laser on

}

else

{

ClearBit(0); //turn laser off

}

This seems easier, and doesn't need changes to the gcode, but I don't know how I could pause motion for a short time after turning the laser on/off. I expect that the multitasking nature of kflop means that the motion controller would keep the laser moving, even if I put some sort of wait function after the setbit and clearbit int the c code... is that true?

Cheers,

Tim

I'm sorry that the topic isn't really representative of my post, but I don't know how to change it.

Tim,

I would suggest you use a solid state relay like the one below they have no arc when they close so are much quieter and faster than mechanical relays. These relays can operate off anywhere from 3.5 to 32VDC, and the come in various amperages and they make them to control DC or AC. The one below should work fine for your application. The KFLOP outputs could be used to provide the ground and connect 5V to pin 4 of the relay. KFLOP has some 5V tolerate output but don't think it has any 5V outputs. The output of this particular relay can handle all the way up to 100VDC. I use there for all kinds of CNC applications they work great.

Using M-codes to control laser on and off seems reasonable. You might want to write a post processor to get all the Gcode updated prior to use. You also might want to search on posts from people doing plasma cutters and see what scheme they are using as well. I might have to get a 3W laser diode and make it an option on my CNC, saw on youtube they can actually do a pretty nice job and they are not terribly expensive these days.

http://www.ebay.com/itm/CRYDOM-SOLID-STATE-RELAY-D1D20-/221639902519?pt=LH_DefaultDomain_0&hash=item339ac48537

Russ

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Saturday, January 17, 2015 9:16 AM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Will an M-code calling a thread wait until it's returned?

Does that sound like a fairly logical method?

The second approach that I was considering, was not to use the M-codes at all, and basically execute a c program that turns on the laser on if the z value matches the engraving value. eg:

if(ch2->Position==-0.2) // If gcode says to lower engraving tool

{

SetBit(0); //turn laser on

}

else

{

ClearBit(0); //turn laser off

}

Cheers,

Tim

Hi Tim,

I think the best approach would be to use a Transistor or Solid State Relay to avoid delays in switching the Laser on and off. Then in this case you can use an MCode configured as an embedded IO command. See:

http://www.dynomotion.com/Help/KMotionCNC/SynchronousIOCommands.htm

This would allow the job to run in a perfectly deterministic manner with no delays. The problem with using MCodes configured as C Programs for things like this is that the PC (and Windows) is involved in waiting for the motion to complete, downloading the C Program , executing it, waiting for it to complete, refilling the motion queue, and resuming motion. This normally happens in milliseconds, but depending on what Windows is doing may on rare occasions have something like a 1 second delay.

HTH

Regards

Group: DynoMotion	Message: 10858	From: timbosaurus	Date: 1/17/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Thanks Russ and Tom, those are both invaluable suggestions, I am so glad I asked!

Russ,

Thanks, I'll take your suggestion on board and go straight to a SSR then.

Unfortunately, time pressures mean I cant wait for postage, and (as always) the only local shop in Australia want $47 for the same thing.... so I think I'll try this cheaper option first -> (http://www.jaycar.com.au/productView.asp?ID=SY4093&form=CAT2&SUBCATID=979#1)

In the future I will be switching to an alternative dxf->gcode program which has editable post processors, but I have already setup this job in f-engrave (which only has editable header/footers), hence find/replace being the only option.

The job was setup to use a diamond drag tip, and worked fine on pieces of scrap, but the production anodising is as hard as rock, so the diamond drag doesn't want to penetrate it... hence the urgent swap to laser.

FYI, my 3W laser is a 9mm 445nm laser with 2.4A x-drive from here: (https://sites.google.com/site/dtrlpf/home/diodes/9mm-445nm). I've only tried it handheld, but I can make lines in the anodising (as fine as hair!) when I get the focus right, so I'm urgently setting up the heatsink/power supply/switching circuits now to support it.

Tom,

Those synchronous commands will make it sooooo much easier, I had no idea about them!

So I will use that, but it does show that I misunderstood how the threads were actually managed. I thought I would download/compile the thread onto kflop in KMotion, then switch to KMotionCNC to start the g-code, and KmotionCNC simply told kflop to execute the thread as requested.

But if I understand what you're saying correctly, the thread will always remain on the PC as an actual .c file and is only compiled/downloaded/executed by KmotionCNC after the M11x code is executed in the gcode? I can see why that wouldn't be very deterministic at all.

Let me go play, and get back to you with the results!

Cheers,

Tim

Group: DynoMotion	Message: 10863	From: timbosaurus	Date: 1/18/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Thanks guys, the laser is a complete success!

My G-code uses M3 to switch on the laser and M5 to switch it off.

I've configured M3 and M5 as synchronous I/O in KMotionCNC... M3 sets I/O bit 0 to 1, and M5 sets I/O bit 0 to 0, and I've also setup quick buttons on the KMotionCNC home screen to turn on/off the laser.

JP33 pin 1 & 2 (Kstep relay driver) is used to swich on the solid state relay (12v Power source -> relay coil -> kstep -> gnd), and everything switches on so fast that there is no need for any delays.

I'm a happy kflop camper once again!

Cheers,

Tim

Group: DynoMotion	Message: 10864	From: TK	Date: 1/18/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Great Tim. Where's the video? :)

TK

On Jan 18, 2015, at 7:57 AM, timbosaurus@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

Thanks guys, the laser is a complete success!

My G-code uses M3 to switch on the laser and M5 to switch it off.

I've configured M3 and M5 as synchronous I/O in KMotionCNC... M3 sets I/O bit 0 to 1, and M5 sets I/O bit 0 to 0, and I've also setup quick buttons on the KMotionCNC home screen to turn on/off the laser.

JP33 pin 1 & 2 (Kstep relay driver) is used to swich on the solid state relay (12v Power source -> relay coil -> kstep -> gnd), and everything switches on so fast that there is no need for any delays.

I'm a happy kflop camper once again!

Cheers,
Tim

Group: DynoMotion	Message: 10876	From: timbosaurus	Date: 1/19/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Attachments :

SSR-10876.jpg

Laser-10876.jpg

finish-10876.jpg

I would love to upload a video, but I'm retarded when it comes to video editing and I cant attach a file bigger than 10MB here. :(

I'll upload to youtube when I get a chance, but pics will have to do for now! :)

The laser is inserted into a video card heatsink for now to keep it cool, and the SSR is just temporarily mounted. It works so well that I'll have to permanently fit it all into my enclosure now!

Thanks for the help guys!

@@attachment@@

Group: DynoMotion	Message: 10881	From: timbosaurus	Date: 1/19/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Yup, MIL spec plastic hand clamp :)

Group: DynoMotion	Message: 10846	From: timbosaurus	Date: 1/17/2015
Subject: Will an M-code calling a thread wait until it's returned?

Group: DynoMotion	Message: 10847	From: timbosaurus	Date: 1/17/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Group: DynoMotion	Message: 10848	From: Russ Larson	Date: 1/17/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?

Group: DynoMotion	Message: 10851	From: Tom Kerekes	Date: 1/17/2015
Subject: Re: Will an M-code calling a thread wait until it's returned?